Linking Leadership and Technical Execution in unprecedented Systems-of-Systems Acquisitions

ions and models help leaders and managers know what details can be “left in the design space”. However, there is a danger. Box observed that “all models are wrong, but some are useful” (Box, 1979). The architect must utilize this fact in a delicate balancing act. In one way, choosing models that managers may already know will help determine which details are unimportant to the given level of discussion, and thus can be left to the designers and developers. However, when the architect is working with an unprecedented system, or a system in an unprecedented context, models from previous experience may abstract away details that, while previously unimportant, are now essential to the success of this unprecedented system. For a SoS, Box's statement is even more confounding. Constituent systems may have architectures that provide insight that was appropriate during their individual developments. When composed with a number of other systems, a quality that is unmodeled in any of the systems may become essential for the SoS to achieve its goals. In this way, the models and architectures selected for the component systems may not truly inform what needs to be modeled at the SoS architecture level. Thus, architecting an unprecedented SoS is a difficult activity for the architect. The architect must figure out what methods to employ, with the understanding that the previous experience and currently utilized models may be inadequate for expressing the scope of the system to the various stakeholders. Over reliance on a priori models may result in the utilization of models that do not appropriately reflect the reality of the system, or worse, force design decisions that can cripple the needed system. In a similar fashion, leaders and managers of architects must work with the fact that because the SoS is unprecedented, that they must both shape themselves and the architects to do what is necessary to deliver a successful system. Finally, acquisition technical architectures provide the mechanism between which technical and non-technical programmatic elements harmonize the acquisition environment. Elements such as budgets, contractual vehicles, multiple requirements communities, and multiple user communities must be served by the leadership and management of the acquisition. Many of these elements may have questions requiring technical analysis. Depending on the phase of the program lifecycle, the technical execution may be within the program office (during concept definition), with the prime contractor (during system design and production) or in the operating organization (while the system is operational). Thus the architects must consider all the issues raised in developing a SoS architecture to serve all these stakeholders. 4. Observed Case Studies of System-of-Systems technical (architectural) interaction The following three different cases were selected because they are representative of the three aspects of the acquisition lifecycle of a SoS mentioned earlier; development of an unprecedented technology, the operationalization of a SoS, and the verification that the developed SoS meets the user’s needs. The three selected cases are briefly presented Journal of Integrated Design and Process Science June 2007, Special Issue